Release 10.1A: OpenEdge Data Management:
DataServer for Microsoft SQL Server
Defining a view to use as a buffer
As an alternative to using the buffer
proc–text–bufferdefined by Progress, you can define a view in the data source that can serve as a buffer allowing you to retrieve database results in their original data types. However, keep in mind that using views creates a database dependency beyond the stored procedure itself.Technique to define a view to use as a buffer
While a stored procedure can include multiple SQL statements, a buffer that you define contains the format of only a single results set. You need to define multiple views to accommodate multiple results sets.
![]()
To define a buffer:
- Define a view in the MSS data source with the following characteristics:
- The naming convention
_BUFFER_buffername.- The same number of columns and data types that the stored procedure returns in the results set.
- The columns in the order that the stored procedure returns them.
For example, to return two columns with two types of values, an integer and a character string, use an SQL utility to define the following view in the data source:
Notice that these views are defined to ensure that they never return any results. This helps to indicate that the purpose of the view is its buffer content and not its SQL capabilities. It is not necessary to define views that you will use as buffers this way, but it does allow you to distinguish quickly between views and buffers.
- Update your schema image using the Update/Add Table Definitions DataServer utility. The utility adds the view to the list of accessible objects in the schema holder. The DataServer defines the view as a buffer that Progress can use. (See the "Updating a schema holder" section for instructions on using this utility.)
Assessing result sets obtained by defining a view as buffer technique
The buffer in the previous procedure defines two returned values for a stored procedure—an
INTEGERand aCHARACTERvalue—in that order. If the data types do not match those returned by the stored procedure, the procedure returns more than two values, or returns the values in a different order than you specified, you receive a run-time error.The easiest way to create a buffer that accepts data from stored procedures is to use the text of the SQL
SELECTstatement from the stored procedure. This ensures that you define your data types correctly and in the correct order. Use a native process such assp_helptextto view the stored procedure from a MS SQL Server, or view procedures in the system tables.The examples in this section do not use the supplied
proc-text-bufferbuffer. Instead, they show how to define formatted buffers by creating views in the data source, using the following syntax:
Example 3–8 and Example 3–9, show the views created in your MSS data source that you can use as buffers to store the results from the stored procedure pcust.
Example 3–8: First view created in your MSS data source
Example 3–9: Second view created in your MSS data sourceThe 4GL procedure in Example 3–10 shows the results of the previous stored procedure
pcustas it is written into the new bufferspcust_ordersandpcust_states.
Example 3–10: Result set of pcust - typed buffersBecause two different buffers have been defined, the returned values maintain their data types instead of being converted to character strings and stored in the Progress-defined buffer
proc–text–buffer. You can then use the returned values in calculations without first converting them back to their original data types. In addition, the two separate buffers make your output look cleaner, allowing the 4GL to build a new default frame for the two different types of output. Reading your results into an explicitly defined buffer also allows you to manipulate the data just as you would manipulate data from an OpenEdge database; for example, with Frame phrases andFORMstatements.Example 3–11 accesses the stored procedure
pcusttwice; procedure handles (through thePROC–HANDLEfunction) identify the different results from your data source.
Example 3–11: Procedure handlesThe results look the same as in the first two examples. However, because you are running a stored procedure twice, the 4GL uses the procedure handles to identify the different instances. If you have more than one stored procedure open simultaneously in your application, you must explicitly define procedure handles for each.
Example 3–12, shows how to use standard Progress syntax to join the results from a stored procedure with other tables in the database:
Example 3–12: Joining stored procedure results with other database tablesExample 3–12 joins the order information returned from the stored procedure with the
order–lineinformation in the same database.
|
Copyright © 2005 Progress Software Corporation www.progress.com Voice: (781) 280-4000 Fax: (781) 280-4095 |